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REMARKS 



Claims 1 and 3-21 remain pending in the application. Claims 1, 3-16, 18 and 20 
have been amended clarify the subject matter contained therein and emphasize the novel 
aspects of the present application. Specifically, the independent claims have been 
amended to require the multi-modal browser be enabled for receiving user supplied 
information by both verbal and tactile interaction, and further, by requiring a command to 
be issued for submitting, resetting or cancelling the form. Support for these amendments 
can be found throughout the specification. Claim 21 has been amended to correctly 
depend from claim 20. Accordingly, the Applicant respectfully requests withdrawal of 
the rejection of claim 21 under 35 U.S.C. §1.75(c). No new issues are raised by this 
amendment. 

Claims 1, 3-4 and 6-21 have been rejected as being unpatentable over U.S. Patent 
6,400,806 to Uppaluru. Claim 5 has been rejected as being unpatentable over Uppaluru 
in view of U.S. Patent 5,101,375 to Goldhor. These rejections are respectfully traversed 
in view of the amendments above and remarks below. 

Claim 1, as amended, requires a computer implemented method for completing a 
form presented on a multi-modal browser for submission to an application program , 
comprising the steps of: 

providing to the multi-modal browser a form having one or more fields requiring 
user supplied informatio n, said multi-modal browser being capable of both verbal and 
tactile interaction with a user, said form having variable content and form fields ; 

prompting by the multi-modal browser a user to fill in a form field by verbal or 
tactile interaction, or a combination of verbal and tactile interaction; 

moving to another form field requiring user provided input either after a current 
form field has been filled in by the user or the user selects by verbal or tactile interaction 
another form field; and 
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using a command to submit the form after the user has supplied input for all 
required fields , or to cancel or reset the form; 

wherein said multi-modal browser continues to prompt the user until the form is 
completed . 

As embodied in claim 1, the present invention concerns a system and method for 
filing out and completing HTML forms sent to a multi-modal browser by providing a 
synchronized presentation of the verbal and visual components. The system and method 
disclosed by the present invention allows the user to fill in and complete such an HTML 
form by utilizing verbal or tactile interaction, or both. As explained in pages 5-6 of the 
specification, and as shown in Figure 1, the multi-modal browser reads the audio 
elements of the form 100 and automatically types in the user's verbal commands. The 
system and method of the present invention does not require the prior creation of a profile 
page to enter data in HTML forms using audio or tactile data entry methods. Rather, the 
present invention allows any HTML form to be filled out, completed, and submitted to an 
application. Neither reference cited by the Examiner, either alone or in combination, 
teach or suggest the system and method disclosed by the present invention. 

Uppaluru is not focused on navigating and completing forms. The Uppaluru 
system does not provide prompting to the user, and does not move to diff erent fields 
based on user input or completion of a current form. Rather, Uppaluru is a system which 
allows navigation of the web with oral (audible) input. Furthermore, Uppaluru requires a 
user to complete a specific personal profile prior to accessing certain pages. 

As explained in Uppaluru, navigation is achieved by extending the HTML anchor 
tag with the attributes of tone and label, and by using commands such as "next", 
"previous", "reload", "home", "bookmarks", "help", "stop", "start", "play", "exit", etc. 
(see column 8, lines 37-56). Uppaluru explains that HVML forms use the form tag to 
enable user input similar to HTML (see paragraph bridging columns 8 and 9), and the 
HVML browser pauses at each voice-input statement in a HVML form until the specified 
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input is supplied or input is terminated, before processing the remaining form (see 
column 8, lines 65-68). This functionality is not the same as, and is unrelated to, 
requiring a user to complete specific fields within a form. 

The Examiner has referenced column 10, lines 34 to column 11, line 14 for the 
use of web forms. This discussion in Uppaluru references a user's creation of a calendar, 
and subsequent retrieval of calendar information is provided as an example. As is self- 
evident from the discussion, the forms gather information from a service database 202 
and use the retrieved data in place of corresponding variables stored in an HVML 
template. This system described in Uppaluru allows subscribers to enter and retrieve 
information without having to create a voice web page for each entry in the service 
database. In other words, a user of the Uppaluru system must enter in personal profile 
information prior to the use of web forms . Furthermore, it is clear that a user of the 
Uppaluru system is not required to complete certain required fields on a form. Rather, the 
user is only able to retrieve whatever it was that he previously entered or requested. At 
no point does Uppaluru require or suggest that the browser stays within the form 
(continuing to prompt) until the form is completed (see pages 8-9 of the specification). 
As such, independent claims 1,18 and 20, as amended, as well as the dependent claims 
are not obvious over the Uppaluru reference. 

With regard to the navigational aspects of the present invention, normal browsers, 
while they do contain a sequence of "things" to be displayed (making it a queue of sorts), 
do not provide these features, and Uppaluru does not provide these features. The concept 
of adding audible features to the output are valuable in situations where a user of a multi 
modal browser (audio/tactile) has had their visual attention taken from the browser. The 
addition of specific sounds can be used to draw a user's attention to a specific or 
"important" part of the output. 

With regard to the rejection of claim 5, Goldhor teaches the capitalization of 
various letters in a text string generated by a voice recognition function. The Goldhor 
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reference does not relate to the subject of claim 5 which requires only a step of typing into 
the form field words responsively spoken by the user. There is no requirement of 
capitalization. Therefore, no combination of Uppaluru with Goldhor would provide for 
the subject matter contained in claim 5 of the present invention. 

Should the Examiner find the application to be other than in condition for 
allowance, the Examiner is requested to contact the undersigned at the local telephone 
number listed below to discuss any other changes deemed necessary in a telephonic or 
personal interview. 

A provisional petition is hereby made for any extension of time necessary for the 
continued pendency during the life of this application. Please charge any fees for such 
provisional petition and any deficiencies in fees and credit any overpayment of fees to Appi 
cants ' * Deposit Account No. 09-0457 (IBM Endicott). 



Respectfully submitted, 
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